home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Aug 90 / MacApp.Tech$ 8⁄17⁄90 / 1766-RE[2] Performance w⁄-Aug90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.2 KB  |  68 lines  |  [TEXT/GEOL]
  1. Item    9433367                         16-Aug-90        00:35PDT
  2.  
  3. From:   AUST0338                        AUPtnr - Tactics Int'l,Shillito,IDV
  4.  
  5. To:     ROSENSTEIN1                     Rosenstein, Larry
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    RE[2] Performance w/too many
  10.  
  11. To:         ROSENSTEIN1 - Larry Rosenstein
  12. From:       AUST0338 - David Shillito
  13. Date:       Thursday 16th August 1990
  14. Subject:    RE: Performance with too many handles
  15.  
  16. Larry,
  17.  
  18. Thank you for your detailed response to my link.
  19.  
  20. I will try to get hold of the article you mention on using separate heaps,
  21. although there is no chance that I will introduce C++ into this project (or any
  22. other).
  23.  
  24. I have investigated some of your other suggestions. The idea about allocating
  25. more master pointers was a good one I had forgotten about. I was calling
  26. InitUMacApp with 25, ie. getting 25*64 master pointers, which also results in
  27. subsequent increments being 64 master pointers at a time. I have changed the
  28. value moreMast in my heap zone to 1000 before calling InitUMacApp with a value
  29. of 2. This means that I now allocate my master pointers 1000 at a time. However
  30. this made little noticeable difference.
  31.  
  32. I used MacsBug and the HT command to check out the heap fragmenmtation and I
  33. really dont think that "fragmentation" is a problem. I had 16 blocks in the
  34. free list, 20,000 relocatable blocks, 4,500,000 bytes free and most of this was
  35. in one piece in the free list.
  36.  
  37. I thought about which operations that the system does a lot that might involve
  38. scanning through the whole of the heap and decided to put A-trap breakpoints on
  39. CompactMem, ResrvMem, MoveHHi and so on. What I  discovered is that MoveHHi is
  40. called for virtually anything I do, such as moving the cursor and setting a new
  41. cursor region, activating a window and so on. The reason for this is that
  42. segments are being unloaded back in the idle loop and reloaded to do any of
  43. these activities. Each segment load involves a call to LoadMacAppSegment which
  44. calls PreloadSegmentResource which calls LockHandleHigh wich calls MoveHHi. All
  45. of this is as it should be, of course, and I dont wish to mess with it.
  46. However, it seems that calls to MoveHHi could be expensive in an environment
  47. where there are 20,000 blocks in the heap. Which brings us back to the
  48. desirability of separating at least the heap used for code segments from the
  49. heap used for most of my application data.
  50.  
  51. However, perhaps there is a way to affect the layout of the relocatable blocks
  52. in memory that will reduce the amount of work MoveHHi has to do. I am starting
  53. to get out of my depth here, but is it possible that the code segmenmts
  54. involved were first loaded early on and now sit below my 20,000 blocks and
  55. MoveHHi has to scan over all of them; whereas if the code segments could be
  56. completely removed from memory and reallocated higher in the heap the amount of
  57. overhead could be reduced?
  58.  
  59. By the way, my objections (perhaps they are spurious but this decision was made
  60. about 2 years ago) to using objects instead of just handles for my dynamic data
  61. structures include:
  62. 1. The additional memory overhead for a TObject.
  63. 2. The additional runtime and space overhead when running in debug while the
  64. inspector adds each new object to its lists.
  65.  
  66. David Shillito
  67.  
  68.